home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001220_dsr@hplb.hpl.hp.com _Tue Jun 1 18:30:44 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA00536; Tue, 1 Jun 93 18:30:44 MET DST
  4. Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA27859; Tue, 1 Jun 1993 18:52:21 +0200
  6. Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
  7.     id AA03259 (5.65b/CWI-2.220); Tue, 1 Jun 1993 18:52:12 +0200
  8. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 1 Jun 93 15:22:39 +0100
  9. Received: by manuel.hpl.hp.com
  10.     (16.6/15.6+ISC) id AA10286; Tue, 1 Jun 93 15:28:21 +0100
  11. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  12. Message-Id: <9306011428.AA10286@manuel.hpl.hp.com>
  13. Subject: Re  STRONG, B, I, and U
  14. To: janssen@parc.xerox.com
  15. Date: Tue, 1 Jun 93 15:28:20 BST
  16. Cc: www-talk@nxoc01.cern.ch
  17. Mailer: Elm [revision: 66.36.1.1]
  18.  
  19. >> I don't like them either. They are present in HTML to support
  20. >> importing (scanned) documents for which a filter has no way of deciding
  21. >> the original meaning.
  22.  
  23. > This justification doesn't sound terribly good.  If we can't infer the
  24. > meaning of the font changes, perhaps translating the scanned document to
  25. > HTML is inappropriate; perhaps the scanned document should be stored in
  26. > TeX or Postscript or GIF, depending on what other image characteristics
  27. > of the document seem important.  Or perhaps the font change information
  28. > should simply be discarded on conversion to HTML, as it does not
  29. > translate to meaning.
  30.  
  31. I think this is perhaps a bit extreme, and in practice most people would
  32. prefer some preservation of italic emphasis etc.  (an empirical question)
  33.  
  34. > Or perhaps the right way to think of these is to apply the output rules,
  35. > in reverse.  That is, the user can specify how <EMPH> is to be formatted
  36. > on output; similarly, perhaps the user could specify how bold font is to
  37. > be interpreted on input.
  38.  
  39. Perhaps we ought to use <EMPH> for all inline emphasis! This gets around
  40. the problem in dealing with every growing categories for different needs.
  41. You then would see elements like:
  42.  
  43.         <EMPH tag="author">H. G. Wells</EMPH>
  44.  
  45. The Web could then have an evolving set of well known categories.
  46. Unrecognised categories would simply be ignored by the browser. Users
  47. would also be able to change how the browser renders each category.
  48.  
  49. Dave Raggett